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The Advanced Interactive Executive (AIX) is the operat¬ 
ing system used in the RT Personal Computer, It is a 
portable operating system architecture that is suitable 
for a wide range of computer architectures and cus¬ 
tomer requirements. Discussed in this paper are the 
structure and services of AIX. 


T his paper discusses Ihe operating system for the 
RT Personal Computer'"’ that is known as the 
Advanced Interactive Executive (aix)'"*. The rt Per¬ 
sonal Computer system is a family of workstations 
based on the ibm 32-bit (Rise) microprocessor- 
named ROMP —and its corresponding high-function 
memory^ management unit.* (rt Personal Computer, 
Advanced Interactive Executive, and aix are trade¬ 
marks of the International Business Machines Cor¬ 
poration.) With this level of performance and func¬ 
tionality, IBM workstations reached the point at 
which it was practical and imperative to provide 
workstation users with an operating system that was 
as sophisticated as those used in mainframe com¬ 
puters. There were many considerations that com¬ 
pelled us to build an operating system for the rt 
Personal Computer that incorporated many of the 
currently most advanced system concepts. 

The RT Personal Computer system includes sophis¬ 
ticated hardware features, such as high-function vir¬ 
tual storage, advanced all-points-addressable (apa) 
displays, real-time capability, and others, which can 
be fully exploited only by equally sophisticated soft¬ 
ware. Because most workstations operate in an in¬ 
creasingly interconnected environment, the operat¬ 
ing system must be able to deal with communication 


functions—especially those that are taking place at 
the request of other users—without intervention by 
the workstation’s user. In many cases, the distribu¬ 
tion of resources is not uniform. Users need to be 
able to use programs, data, and peripheral devices 
that are not local to their own workstations. Perhaps 
most important is the fact that workstations require 
an operating system that provides an application 
execution environment that combines application 
program portability from ibm and industry environ¬ 
ments with efficient use of the hardware. 

We decided to base the core of the rt Personal 
Computer operating system on the at&t unix^ Sys¬ 
tem V. (UNIX is developed and licensed by at&t, 
and is a registered trademark of at&t in the U.S.A. 
and other countries.) In addition to System V, we 
included many enhancements generally available in 
the industry, most notably some features of System 
V.2, and many from bsd (Berkeley Software Distri¬ 
bution) 4.2 and 4.3. (BSD 4.2 and 4.3 are variants of the 
UNIX system developed and distributed by the Uni¬ 
versity of California at Berkeley.) We chose the Unix 
operating system because it provides significant 
power to a workstation user, provides multiuser ca¬ 
pabilities when needed, and is portable and open- 
ended. .Also important is the fact that the Unix 
system has a large user and application base. In 
choosing the Unix system, we accepted the need to 
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make significant upwardly compatible enhance¬ 
ments over what was available in the industry to 
meet our requirements. As is traditional for unix- 
based operating systems, an acronym ending in ix 
was chosen: thus we have aix. 

UNIX concepts 

The LMX operating system was originally created in 
the 1970$ to provide a test bed for computer science 
experimentation.^ This operating system differs from 
conventional operating systems in several key ways. 
Essentially, all of the operating system code is written 
in c to ensure easy portability from one processor 
architecture to another. Most of the control struc¬ 
tures of the operating system, such as configuration 
tables, are bound as late as possible. Configuration 
information is kept in editable files to allow easy 
modification for experimental purposes. The file sys¬ 
tem, often called the heart of the Unix system, is a 
tree-structured hierarchy consisting of directories 
and files. Files are represented as linear byte spaces 
rather than records and fields. Directories are struc¬ 
tured files describing files and other directories. In 
keeping with the objective of portability, most i/o is 
performed through generic devices. The generic de- 
\ ices are mapped to real i/o devices by user-replace¬ 
able routines called device drivers. Any part of the 
nucleus of the system (called the kernel) can be 
modified by an appropriately authorized user. A 
command-processing component (called a shell) per¬ 
forms parameter substitution and calls appropriate 
command programs. No real distinction is made 
between command processors supplied with the op¬ 
erating system and those written by the user that 
accept the same invocation parameter conventions, 
and several shells can coexist in a given system. 

Figure 1 shows the overall structure of a typical UNix 
system. The most significant difference from ordi¬ 
nary' operating systems is the accessibility of all ele¬ 
ments of the software to user modification. A Unix 
system is thus an operating system that provides 
tools for its own redefinition. It is precisely this 
characteristic that has made it the most popular 
operating system in academic computer science. 
Many of the commands and facilities that were 
originally developed in the course of computer sci¬ 
ence experiments have found their way into produc¬ 
tion UNIX systems. This has greatly enriched the Unix 
functional power, while contributing a certain 
amount of inconsistency, especially in the syntax of 
the command language. 


AIX structure 

The generality and portability of the unix system 
are achieved at some cost in optimum use of the 
underlying hardware. We had decided to start with 
the UNIX system as a base. In view of our require¬ 
ments, however, we were faced with the question of 
how best to provide the required enhancements. Two 
strategies could be followed. One was to rewrite the 
entire kernel. Although theoretically p>ossible, be¬ 
cause of the amount of unix knowledge available in 
IBM at the time, it was unlikely that such an approach 
would achieve upward compatibility with the stan¬ 
dard UNIX system. The other was to provide a set of 
software services for the kernel and modify the kernel 
and other functions to exploit the facilities provided 
by that layer. We chose the second approach, which 
led to the system structure shown in Figure 2. 

The Virtual Resource Manager (vrm) controls the 
real hardware and provides a stable, high-level ma¬ 
chine interface to the advanced hardware features 
and devices. (See Figure 3.) The kernel received 
corresponding enhancements to use the services of 
the VRM and to provide essential additional facilities. 
Although the vrm and the aix kernel proper have 
been tuned to each other, we have not precluded the 
ability to build other operating systems to exploit 
the \ R.M services. Similarly, the techniques we used 
to virtualize existing types of devices would work for 
new device types as well. Both the vrm and the 
kernel have been deliberately made open-ended to 
allow* the straightforward addition of new functions 
and device support. 

We were dealing with a new hardware architecture 
and with large quantities of new and modified soft¬ 
ware in the system. Because of that, we felt that 
special efforts were required to ensure excellent per¬ 
formance. We adopted a policy of continuous per¬ 
formance assessment of the operating system, start¬ 
ing with the earliest availability of hardware and 
software. The performance group had to develop 
new tools and procedures to assess the performance 
of the system, while it was still immature. The results 
ot that effort arc visible in the performance of the 
completed product. 

To achieve one of our primary- goals of providing 
users the widest possible choice of applications and 
computing environments, we provided ways of mov¬ 
ing applications and data to the rt Personal Com¬ 
puter from other systems, such as the ibm Personal 
Computer, other unix systems, and ibm mainframes. 
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Figure 1 Typical UNIX system structure 
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Figure 3 Interface levels of AIX 
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as well as many ways lo interconnect them. The 
application development extensions above the kernel 
were integrated into the existing operating system 
structure. In some cases, the extensions were pack¬ 
aged and priced separately, but they were designed 
to operate as integral parts of the operating system 
after installation. 

Creating a virtual environment for the AIX kernel 

The existing structure and functions of the Unix 
kernel were not sufficient for exploiting the advanced 
features of the rt Personal Computer hardware. The 
major deficiencies fell into the following areas: 

• Lack of virtual-memory support had been a {per¬ 
ceived deficiency in earlier systems. However, 
there were UNix-based systems, such as bsd 4.2, 
that had provided virtual memory, but none of 
these had the capabilities that were possible with 
the RT Personal Computer. 


• There was limited program management with 
code sharing only at the program level and static 
binding of modules. 

• Real-time facilities, such as absolute priorities, 
kernel-level pre-emption, and multiple-process 
I/O, were lacking. These facilities were thought 
useful not only for traditional real-time applica¬ 
tions, but also for complex communications ser¬ 
vices. 

• There were limited facilities for dealing with dy¬ 
namic I/O configurations. Most i/o changes re¬ 
quired the rebinding of the kernel. 

Instead of making major changes to the architecture 
of the kernel, we used the vrm to provide facilities 
to overcome these shortcomings. The vrm provides 
the services to implement a multitasking op)erating 
system while insulating the kernel from most of the 
details of the hardware implementation. The kernel 
has to be aware of only the problem-state instruc¬ 
tions. All the other services, such as i/o device sup- 
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Figure 4 Virtual Resource Manager (VRM) structure 
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port, storage management of disk and memory, and 
hardware initialization, are provided. The vrm ser¬ 
vices are implemented in a comprehensive real-time 
execution environment.^ Figure 4 shows the overall 
structure of the vrm. 

VRM nucleus. The nucleus contains the basic ser¬ 
vices for the control of the romp processor, Memory 
Management Unit (mmu), and I/O Channel Control¬ 
ler (locc). These services include multiple pre-empt- 
able processes, process creation and priority control. 


dynamic run-time binding of code, direct control of 
virtual memory, millisecond-level timer control, 
multiple pre-emptable interrupt levels, and an effi¬ 
cient interprocess communication mechanism for 
main and interrupt-level processes. 

There is a virtual machine interface (vmi) that oper¬ 
ates as follows. The kernel accesses the facilities of 
the VRM via a set of supervisor calls (sve), virtual 
interrupts, and shared memory control blocks. Ser¬ 
vices may be executed synchronously as a call/return 
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or asynchronously via a queue to a device driver or 
process. These services provide the kernel with the 
capability of enabling and disabling virtual inter¬ 
rupts, returning from a virtual interrupt, processing 
machine communications interrupts such as a stor¬ 
age exception, and dispatching an operating system 
process. These are the basic facilities provided to 
implement a multitasking operating system kernel. 

Storage management. A minidisk manager (mdm) 
provides the services to partition disk storage into 
logical areas that are independently managed. A 
minidisk is a contiguous area of disk storage that can 
be accessed by a logical block number, the size of 
which is specified by the kernel. This service also 
provides error recovery and bad block relocation. 
The VRM resides on a minidisk of its own in a 
standard aix file system. Installation and space man¬ 
agement on that minidisk are performed with stan¬ 
dard AIX utilities. 

Virtual memory manager (VMM). The romp/mmu 
virtual memory architecture, in combination with 


the VRM, gives the rt Personal Computer a demand- 
paged virtual memory of 1 terabyte, consisting of 
4096 256-megabyte segments. Segments have a max¬ 
imum of 256 megabytes, but typically they are much 
smaller. The romp contains 16-segment registers, 
permitting the addressing of 14 segments [plus i/o 
and Direct Memory Access (dma) operations] at any 
time. (See Figure 5.) The vrm performs page-fault 
handling and manages the allocation of real memory, 
paging space, and virtual storage segments."^ The vrm 
also provides the aix kernel with interfaces to control 
these functions and to respond to a page fault by 
dispatching another process. These services provide 
a view of virtual memory as a collection of segments 
and pages that can be managed via svcs. The segment 
ser\ices include create, destroy, change length, and 
protection, with a load-and-clear segment register(s) 
to provide addressability. A copy service that delays 
copying pages until they are referenced provides the 
necessary' support for the Unix fork primitive. The 
page serv ices that pin, unpin, change protection, and 
purge provide other basic mechanisms for the kernel 


Figure 5 Virtual memory addressing 



32-BIT ADDRESS FROM CPU 


16-SEGMENT REGISTERS 


40-BIT VIRTUAL ADDRESS 
(i.e., 2^^ = 4096 SEGMENTS; 

2^® » 256 MB MAXIMUM SEGMENT SIZE) 


IBM SYSTEMS X)URNAL. VOL 26, NO 4 1987 


LOUCKS AND SAUER 331 




































Figure 6 Device handler structure 



to use in controlling the virtual memory environ¬ 
ment. 

The VRM also provides a map page service that maps 
memory pages within a given segment onto discon¬ 
tinuous disk file blocks, thus providing the primitive 
support for creating a single-level store that makes 
disk and memory access equivalent operations. 

I/O subsystem. The vrm provides the operating 
system with an extensive queued interface to the i/O 
devices, thereby insulating the kernel from the details 
of specific devices and the management of shared 


devices. The devices that the kernel typically sees are 
those that are generic, such as generalized fixed-disk 
drives (i.e., minidisks) or serial ports. In those cases 
in which the generic devices are not appropriate or 
in which the real-time capabilities of the vrm envi¬ 
ronment are needed by the application, the user or 
a third-party programmer can write c or assembler- 
language code to implement the necessary function 
and dynamically add that code to the vrm. 

Configuration. The configuration services provide 
facilities to add device support to the vrm. The 
Define Code sve binds an executable module, called 
a device handler, into the vrm and Define Device 
provides the device-specific parameters to the han¬ 
dler. The correct device handler is typically selected 
on the basis of the currently installed hardware or 
via operating system configuration files and is dy¬ 
namically bound into the vrm at start-up. However, 
these svcs may be issued to the vrm at any time. A 
Query sve provides the ability to determine the 
current configuration. 

Device handler. A device handler is a very structured 
module designed to provide a queued interface to a 
device. There is a well-defined set of entry points 
that implement the functions of the driver; the exe¬ 
cution environment for those entry points is strictly 
controlled by the vrm. (See Figure 6.) A device 
handler is not a process. Therefore, it runs as a part 
of the calling process, i.e., the kernel or another vrm 
internal process, or on a hardware interrupt level. 

Device manager. A device manager is a structured 
VRM process designed to provide additional manage¬ 
ment services that cannot be provided by a device 
handler. (See Figure 7.) The execution environment 
is a VRM process and therefore has all the standard 
process attributes and capabilities, such as the ability 
to exploit virtual memory as well as various inter¬ 
process communication (IPC) mechanisms. 

Virtual terminal subsystem (VTSS). At the time aix 
was being implemented, no standard Unix interface 
for advanced-function apa displays existed. There¬ 
fore, we provided a method to allow multiple appli¬ 
cations to access the local console hardware. The key 
to this ability of aix to support multiple simultane¬ 
ous interactive applications is the virtual terminal.* 
A virtual terminal is a virtual counterpart of the real 
RT Personal Computer display(s), keyboard, locator 
(mouse or tablet), dials (valuator), and lighted pro¬ 
gram function keys (lpfk). The virtual terminals 
time-share the use of the real displays and input 
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devices. A virtual terminal can function either as a 
simulated ascii terminal or as a high-function ter¬ 
minal (hft) equivalent in power to the real hardware. 

ASCII terminal simulation. The simulated ascii ter¬ 
minal resembles a typical "'glass teletype''" (tty), en¬ 
hanced with functions to control sound, multiple 
fonts, and color. The functions are made available 
at the VMi through a set of standard i/o svcs and 
through escapes in the data stream, as allowed in 

ANSI 3.64. 

Monitored mode, ascii terminal support is obviously 
not sufficient to support graphics and image on the 
local console displays. Therefore, an additional mode 
of an HFT (high-function terminal) virtual terminal 
was provided. This facility, called monitored mode, 
provides the support to allow an application in prob¬ 
lem state to obtain controlled access to all hardware 
functions of the display. Also in this mode, data 
from the input devices are placed directly in the 
process address space by the hft support in the vrm. 
The necessary services to control this access are also 
provided. These functions can be accessed directly 
by advanced applications through hft facilities pro¬ 
vided by the kernel, or more appropriately via the 
advanced graphics and windowing services provided 
by Aix. 

HFT implementation. The hft support is one ex¬ 
ample of the type of high-function i/o that can be 
implemented using the services provided by the vrm. 
It currently consists of many device handlers, two 
device-manager processes, and more lines of code 
than any other single vrm function. 

Serviceability. Problem determination in system- or 
user-added code is supported by vrm serviceability 
facilities that include trace capabilities, dump capa¬ 
bilities, and an absolute debugger. 

Personal Computer AT coprocessor. The vrm sup¬ 
ports the Personal Computer at coprocessor option 
as though it were another, albeit rather specialized, 
virtual machine.^^ The coprocessor runs concurrently 
with the execution of programs in the romp, but it 
has access to the keyboard, locator, and display only 
when the coprocessor virtual terminal is the active 
virtual terminal—that is, when it has control of the 
display. The inputs from the keyboard and locator 
are presented to the coprocessor as though they had 
been produced by the corresponding Personal Com¬ 
puter AT devices. If no display has been dedicated to 
the coprocessor, the display interface emulates a pc 
display on the system display. The vrm manages the 


Figure 7 Device manager structure 
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shared system resources to ensure that the romp and 
coprocessor operate cooperatively. 

Building an enhanced kernel 

The structure of the Unix kernel was modified to 
allow it to operate in a vrm execution environment.’ 
The kernel, and all of its processes, op>erate within a 
single virtual machine, as shown in Figure 8, and it 
uses the execution control facilities of the vrm to 
multitask within that machine. The kernel has been 
enhanced to use the vrm virtual memory services, 
and it now provides a demand-paged virtual memory 
system that fully supports the 1-terabyte address 
space. The kernel uses vrm page fault information 
to control process dispatching, as well as allowing 
the kernel itself to be paged. 

The kernel occupies one (256-megabyte) segment. 
The code, computational data, and stacks are all 
contained within that segment. Each process is allo¬ 
cated three segments: one for program text (code), 
one for computational data, and one for the stack, 
as shown in Figure 9. This allocation of virtual 
memory allows very large programs with a very large 
data space to execute on the rt Personal Computer. 
This approach also simplifies many program and 
storage management functions. Functions such as 
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Figure 8 Operating system structure 
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program sharing, compulalional storage allocation, 
and automatic stack growth are easier because all of 
the program sections are consistent among processes 
and arc obviously large enough to allow simple tech¬ 
niques to be used. Additional segments can be ob¬ 
tained for use with private or shared data, shared 
code, or for mapped files. 

Mapped files. A major extension of the file system 
was the exploitation of the vrm map page service to 
create a single-level store environment for program 
text (code) and data. This facility is called mapped 
files. A mapped file is one that is accessed through 
the virtual memory mechanism simply by loading 
data from the appropriate address. A segment can 
contain only one file. Figure 10 shows how files are 
mapped into the program's address space. Executa¬ 
ble files (programs) and static initialized data are 
automatically mapped by the kernel at program 
invocation. A user data file can be mapped after it is 
opened via a simple extension to an existing system 
call. After a data file is mapped into a segment it 
may be accessed using any of the traditional kernel 
file I/O facilities, such as read, write, ..., or it may 
be treated as memor\ and accessed directly. 

Single-level store. Single-level store (sls) technology 
provides a number of significant performance and 
space improvements over traditional methods. For 
programs, the load-and-cxecute method of execution 
requires that the operating system load the entire 
program into its address space before execution may 
begin. In addition, if the real memorv is required for 
other purposes, the program must be paged out to 
backing storage. Contrast that procedure with the 
SLS approach. First, the program is simply mapped 
into the address space and given control at its entry 
point. Only the portions of the program that are 
needed for this invocation are ever actually read into 
real memory. Furthermore, if the real memory is 
required for other purposes, the program does not 
need to be paged out: it is simply paged in when 
required again for execution. This procedure has the 
benefits of quicker program start-up, reduced disk 
space because only a single copy of the program 
exists on disk, and elimination of paging out of 
program code. For data files, the advantages come 
from allowing the virtual memory manager to con¬ 
trol all of the data of a process, both file data and 
computational storage. Therefore, it can allocate real 
memory in a more efficient manner. For example, 
consider a database application that is accessing a 
set of tables 10 megabytes in size, with that applica¬ 
tion executing on a machine that has 16 megabytes 
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of real memory. After a few accesses, the essential 
portions of the database tables are in real memor\', 
and the accesses that in traditional architectures were 
disk accesses are now memory accesses. The char¬ 
acteristic of program execution time changes from 
being i/o-limited to processor-limited, and, since 
processor speeds are increasing at a more rapid rate 
than disk access times, this change in the character¬ 
istic of the program is very beneficial. This is similar 
to the benefits of memory disks on personal com¬ 
puters, except that the allocation of resources is done 
dynamically rather than statically and the process is 
totally transparent to the user as well as to the 
program. 

Database enhancements. Historically, UNix-based 
database programs have used only the low-level disk 
I/O services of the kernel because the standard unix 


file system lacked several key features necessary to 
support them. This resulted in database programs 
that were not integrated with the system, unique sets 
of utility commands to be learned, and a general 
increase in the complexity of the system. We wanted 
to provide an integrated environment. Therefore, 
the kernel file system services were extended to pro¬ 
vide the necessary facilities to allow us to add data 
management and relational database support that is 
built on top of the file system.The enhancements 
included the ability to perform space management 
within a file, buffer cache synchronization on a file 
basis, and file- and record-level locking. 

Performance and structure. We have added many 
performance improvements to the file system. The 
most notable are directory caching to speed up path¬ 
name lookup and the use of 2048-byte blocks. We 
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Figure 11 File system structure 



have restructured the file system using the Sun Mi¬ 
crosystems™ vnode definition to support multiple 
file system types in the kernel.’ Figure 11 illustrates 
this approach. (Sun Microsystems is a trademark of 
Sun Microsystems, Inc.) 

Interprocess communications (IPC). To assist in the 
writing of multiprocess applications, several en¬ 
hancements were added to the standard system V 
IPC packages. 

Signal enhancements. The traditional signal (asyn¬ 
chronous event notification) package has been aug¬ 
mented by a new package, compatible with the 
BSD 4.2 package, that provides more signal manage¬ 
ment services and cures a number of race conditions 
that were inherent in the original services. The stan¬ 
dard signal package remains available for compati¬ 
bility with existing application programs. 

Message queues/ semaphores/shared memory. Mes¬ 
sage queues were enhanced to provide an extended 
message structure that contains information useful 
for implementing security controls in servers. An 
additional option of semaphores reduces the process 
dispatches required in typical multiple-process ap¬ 
plications, and new system calls were added that 
provide additional control over shared memory al¬ 
location and reclamation. 

I/O management. The i/o management area of the 
kernel was restructured to make effective use of the 
I/O facilities of the vrm. Instead of a specialized 
device driver for each distinct device, we created a 
family of generic device drivers that are capable of 
supporting a number of unique devices of a given 
class. Unique device characteristics are supported by 


the VRM device handlers, which can be added or 
replaced dynamically. To implement this, the device¬ 
driver interfaces have been extended to allow dy¬ 
namic binding of a kernel driver to a vrm device 
handler. 

Configuration. In configuring a UNix system, the 
administrator has historically needed an understand¬ 
ing of the internal structure and logic of the UNIX 
system, to be able to edit the configuration files 
correctly. We believed that it was unrealistic to im¬ 
pose such a requirement on our prospective users. 
Therefore, we set out to simplify the installation and 
configuration processes.For those devices that can 
be identified internally, such as displays, the system 
performs an automatic configuration process. For 
devices that require explicit description, such as 
printers, we built a set of menu-driven utilities that 
obtain the necessary information from the user and 
make the required coordinated changes to all of the 
affected vrm and kernel system files. The interfaces 
to these utilities have been documented so that users 
or third-party programmers can add devices to be 
selected and described via the menus. These menus 
use the facilities shown in Figure 12, which were 
provided to allow users to add device and real-time 
application support. 

The I/O is typically configured at system start-up. 
The vrmconfig program, along with the helpers for 
each unique device type, reads the configuration files 
and adds the current device support to the running 
system. Additional support may be added any time 
by simply running vrmconfig. 

Terminal support. The standard terminal support 
facilities of the Unix operating system were extended 
to exploit the capabilities of the vrm local console 
support. In addition, several enhancements were 
made to the general character support that is appli¬ 
cable to all ASCii-class or teletype terminals (com¬ 
monly known as ttys). Figure 13 describes the over¬ 
all Aix terminal structure. 

Activity manager. We developed an activity manager 
to provide the support to manage virtual terminals. 
It has facilities for programs and users, such as to 
create or to terminate a virtual terminal or to start a 
program. 

Character support. The tty generic support was ex¬ 
tended to provide support for screen paging. This 
facility is useful in controlling the output of stream- 
oriented applications, as well as providing a mecha- 
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Figure 12 I/O configuration 



nism to prevent unseen output from going to inactive 
virtual terminals. In addition, an input-editing 
model patterned after the one provided in PC dos 
was provided. 

To allow existing applications to run unchanged and 
new character-oriented applications to use the rt 
Personal Computer facilities fully, we extended the 
ASCII character-oriented terminal model via private 


escape codes in the data stream and a new set of i/o 
controls to access features such as fonts, character 
sets, color, sound, and mouse input. These facilities 
are accessed through the kernel high-function ter¬ 
minal (hft) device driver. 

A package known as CURSES, which is a character- 
oriented window management package designed for 
TTY ASCII terminals, has received performance en- 
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Figure 13 AIX terminal support structure 
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hancements and has been compatibly extended to 
provide access to the extended font and other func¬ 
tions of the RT Personal Computer native displays. 
We also added functions such as screen division and 
layering logic to give applications a high-level, de¬ 
vice-independent interface. 

A PA support. The monitored mode support provided 
by the vrm is managed by the kernel hft device 
driver via a set of i/o controls and signals. These 
facilities ensure proper behavior by applications us¬ 
ing this feature. If an application refuses to relinquish 
control of a virtual terminal, the hft driver, after 
waiting for a specified time period, terminates the 
application. The application selects the mode in 
which to use the virtual terminal. 

The Graphics Support Library (gsl) provides a set 
of high-performance graphic, text, and raster output 
primitives and a set of input functions for the local 


console. These functions are designed to provide an 
application programming interface to applications 
desiring this level of interface, as well as the apa 
device-driver function to higher-level graphics and 
window serv ices. 


Usability extensions 

Single user. Because we expected rt Personal Com¬ 
puters to be used both as single-user workstations 
and as traditional Unix time-shared systems, we 
believed that some changes were required to support 
the workstation user. We have made some altera¬ 
tions to reduce the number of situations in which a 
user has to exercise “superuser” authority. We added 
the ability to define more than one group to which 
a user belongs at any given time. This feature, de¬ 
rived from BSD 4.2, allowed us to define users as 
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members of the system group. System group mem¬ 
bers can perform a number of operations that pre¬ 
viously could be performed only by a superuser; only 
the most hazardous commands are still restricted to 
superuser authority. This technique gives the user of 
a private workstation a simpler environment to work 
in, while preserving the existing aix authority struc¬ 
ture for multiuser environments. For users who wish 
to operate their systems in a manner similar to pc 
systems, a configuration option was added to allow 
automatic log-on at system start-up time. 

Menu shell. The UNIX system has a dual-purpose 
command language. The commands have been de¬ 
signed from the beginning to be primitives of a 
command procedure programming language, some¬ 
times at the expense of ease of use w hen individual 
commands are submitted from the terminal. This 
makes the management of files and the performance 
of common operations unnecessarily complex. 
Many Unix installations solve this problem by build¬ 
ing sets of procedures that effectively constitute a 
command meta-language. We chose to combine the 
solution to this problem with the construction of a 
full-screen interface to aix.” The usability package 
provides Files, which is a full-screen file management 
utility similar to filelist on vm/cms, and Tools, 
which is the ability to request the most common aix 
commands via a menu interface. The dialog manager 
that is used to implement these utilities is general 
enough to serve application programs as well as aix 
commands.*- 

The Files and Tools applications of the usability 
package can be extended to cover new types of files: 
new actions that can be performed against those files 
can be defined: and new tools—including complete 
full-screen applications—can be added. The dialog 
manager in the usability package can also be used to 
provide new full-screen applications with an inter¬ 
face that is consistent with the interface presented b\ 
Files and Tools. 

PC DOS compatibility, aix also includes a new shell 
that processes pc dos commands, conversion pro¬ 
grams that transform data from PC to rt Personal 
Computer format, and subroutines that allow appli¬ 
cations to read DOS-formatted diskettes and mini¬ 
disks.'^ 

National-language support. The i MX system has 
historically been an English-only operating system. 
We have added significant national-language support 
in the following form: 


• An extensive character set including mathematics 
symbols and multinational characters has been 
added. For example, characters such as a, e, tt can 
be included in an rt Personal Computer data 
stream. 

• The formatting of data such as currency, date, and 
time in accordance with the requirements of a 
particular country has been included. For exam¬ 
ple. in some countries dates are traditionally writ¬ 
ten with the year first; in other countries, dates are 
wrinen with the month first. 

• Data processing has been included that is consist¬ 
ent w ith the characteristics of a particular national 
language. For example, the operating system can 
son in alphabetic order, according to the particular 
conventions of each supported country. 

The RT Personal Computer international-character 
suppon benefits more than just non-U.S. English 
users. For example, an extensive character set of over 
500 characters allows users to create text that in¬ 
cludes non-alphanumeric symbols (such as many 
mathematical symbols). 

Diagnosis and debug. To simplify the diagnosis of 
problems in aix. we added several debugging tools 
that include a trace mechanism, a mechanism for 
logging of errors and system messages, and a mem- 
or>-dump capability. The standard facilities were 
extended w here necessary to deal with the unique 
features of aix and the rt Personal Computer hard¬ 
ware. 

Expanding the application development 
environment 

To be able to support the full range of modern 
applications, aix incorporated several functional ex¬ 
tensions. The most significant enhancements have 
been the following: 

• X broad spectrum of technical and commercial 
programming languages 

• An SQL database manager and an indexed access 
method 

• Industry standard graphies subsystems 

• Connectivity enhancements to allow rt Personal 
Computers to communicate with both ibm and 
non-IBM systems, in Local-Area Networks (lans) 
and over Wide-Area Network (wan) telecommu¬ 
nications links 

• Window support services 

• Distributed services for interconnected rt Per¬ 
sonal Computers to be used cooperatively and to 
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allow multiple applications to work effectively on 
the RT Personal Computer 

Languages. The higher-level language compilers for 
the RT Personal Computer were chosen on the basis 
of the number and types of programs that have been 
written in those languages. We selected dialects that 
would facilitate propagation of programs from the 
IBM Personal Computer, other ibm mainframes, and 
other UNIX systems, with language extensions where 
necessary to support the aix environment. In some 
cases, the compilers have two modes—one for pro¬ 
grams from the pc, and one for programs from 
minicomputer or mainframe environments. We de¬ 
veloped a new subroutine linkage convention that 
supports multimodule programs written in several 
languages.''' 

Data management. One of the most critical require¬ 
ments was for a database program supporting ibm 
SQL to provide both users and application program¬ 
mers with relational database facilities. We also 
added a b-tree-based data management program that 
permits either record-level or field-level access. Al¬ 
though these subsystems are packaged separately 
from the operating system, they become an integral 
part of the file system when they are installed. 

Graphics interfaces, aix provides a family of differ¬ 
ent interfaces to the console display. Versions of a 
standard Virtual Device Interface (vdi) and a Graph¬ 
ics Kernel System (GKS) are available from third- 
party vendors. We provide graPHiGS'", an imple¬ 
mentation of the emerging Programmer’s Hierarchi¬ 
cal Interactive Graphics Standard (piiigs). (graPHiGS 
is a trademark of the International Business Ma¬ 
chines Corporation.) This implementation provides 
application portability from ibm mainframes and 
supports all of the graphics device attachments of 
the RT Personal Computer, including the ibm 5085. 

Communications. Because the RT Personal Computer 
is intended to be able to communicate with both ibm 
and non-IBM systems, aix must include support for 
a wide variety of communications protocols, aix 
supports Asynchronous, Bisynchronous (bsc), sdlc, 
CUT, DFT, Ethernet™, and Token-Ring connections. 
We have included both the industry-standard 
tcp/ip and the ibm sna protocols (lu i, 2,3, and 6.2). 
The RT Personal Computer can be a bridge among 
multiple different i.ans, able to support up to two 
Ethernet and two Token-Ring LANs from a single rt 
Personal Computer. Figure 14 summarizes the range 
of connectivity available. (Ethernet is a trademark 
of Xerox, Inc.) 


Figure 14 Summary of RT Personal Computer connectivity 
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Figure 15 X-Windows example 



Window management. Another subsystem that is 
available is the X-Window System. X is a space- 
shared. multiprocess window service that was devel¬ 
oped under the auspices of Project Athena at the 
Massachusetts Institute of Technology.’’ One of the 
key capabilities included in X is the TCP/iP-based 
network support that allows windows to contain data 
from X applications running on other computers 
that are connected via Ethernet or Token Ring. Sec 
Figure 15. 


Distributed Services 

RT Personal Computer Distributed Services (rt/ds) 
provides distributed operating system capabilities for 
the Aix operating system. These include distributed 
files with local/remote transparency, a form of sin¬ 
gle-system image and distributed interprocess com¬ 
munication. The distributed file design supports tra¬ 
ditional AIX and UNIX file system semantics. This 
allows applications, including data management/ 
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database applications, such as SQi rt. to be used in 
the distributed environment without modification to 
existing object code. The design incorporates ibm 
architectures such as sna and some of the architec¬ 
tures of Sun Microsystems nfs.'^ '^ 

Design goals. The primar\' goals in our design of 
distributed services were the following: 

• Local!remote transparency in the services distrib¬ 
uted. From both the user's perspective and the 
application programmer's perspective, local and 
remote access appear the same. 

• Adherence to ai\ semantics and usiix operating 
system semantics. This is corollary to local/remote 
transparency. The distribution of services cannot 
change the semantics of the services. Existing ob¬ 
ject code should run without modification, includ¬ 
ing database management and other code that is 
sensitive to file-system semantics. 

• Remote performance and local performance. This 
is also corollar>^ to transparency. If remote access 
is noticeably more expensive, transparency is lost. 


Note that caching effects can make some distrib¬ 
uted operations faster than a comparable single¬ 
machine operation. 

Setwork media transparency. The system should 
be able to run on different local- and wide-area 
networks. 

• Support of mixed administrative environments. 
W’e believe networks are evolving toward hetero¬ 
geneous collections of private machines, i.e., sin¬ 
gle-system-image clusters of machines, and ma¬ 
chines that act as servers for multiple machine/ 
s\stem images. This necessarily implies multiple 
administrators w'ith complex interrelationships. 
Security and authorization. Comparable to these 
are those for a single multiuser machine. 

file system. Distributed Services uses remote 
mounts to achieve local-remote transparency. A re¬ 
mote mount is much like a conventional mount in 
the LMx operating system, but the mounted file 
system is on a different machine than that mounted 
on director). Once the remote mount is established, 
local and remote files appear in the same directory 


Figure 16 Example shared file system 
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Figure 17 Architectural structure of Distributed Services file system 



hierarchy, and—with minor exceptions—file system 
calls have the same effect regardless of whether files 
(directories) are local or remote. Mounts, both con¬ 
ventional and remote, arc typically made as part of 
system start-up, and thus are established before users 
log on. Additional remote mounts can be established 
during normal system operation. 

Figure 16 gives an example view of a shared file 
system seen by one machine in a single system image 
cluster. Figure 17 illustrates the structure of the rt 
Personal Computer Distributed Services files system 
(RT/DS). 

Concluding remarks 

Aix is a portable operating system. Written mostly 
in the c language, it is intended to be migratable to 
new hardware platforms as they emerge. We believe 
that in aix we have combined a portable and versatile 
industry-standard application programming envi¬ 
ronment with contemporary hardware and operating 
system architecture. The resulting operating system 
is suitable for use with a wide range of computer 
architectures and customer requirements. 
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